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(54) Method md apparatus fdr sharfitg a flme quantum 

(57) A method and apparatus for allOMring a first 
thread (112) to "share** its remaining time quantum with 
a second thread (112) when the first thread is blocked. 
A thread (1 12) may be blocked, for exanple. if it is wait- 
ing for a resource such as a data file or a lock A thread 
may also be blocked if It is waiting for an event, such as 
a user keystroke. If there is a thread on the run queue 
that **Gwns** the resource needed by the consumer 
thread, the bk)cked consumer thread transfers its right 
to execute for a remalrvng time quantum to the owner 
thread, and the owner thread executes neoo. if the 
threads (112) are in a same process (110), this transfer 
means that no process context switch is required, since 
the consumer thread and the owner thread are threads 
of the same process (110). In addition, this transfer 
means that the time before the resource becomes avail- 
able to the blocked consumer thread will t>e short Sim* 
ilarly, if a consumer thread is btocked to await an event 
such as a user keystroke, the t)tocked consumer 
thread's remaining time quantum are transfened to 
another thread in that is waiting on the run queue for its 
turn to execute. Again, if the threads (112) are in a san^ 
process (110). this transfer avoids having to perform a 
context switch between processes. 
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Descrtiition 

HELD OF THE INVENTION 

[00011 This application relates to operating systems 
and. spedTically. to a mettK)d and apparatus that aHows 
thread of a process to share a remaining quantum of 
processor time allotted to it wnth other threads. 

BACKGROUND OF THE INVENTION 

[0002] Most modern computer systems are multi-task- 
ing sydema That is, they allow more than one lob" or 
"prooess" to be active at a given time Since there te 
often only one processor in the system (or a number of 
processors less than the number of jota^rocesses). It 
k>ecomes necessary for the jok>s/proces8es to share the 
processor resources. In a shared processor system, a 
processor spends some time executing part of a first 
job/|proces8 before switching to execute part of another 
jcb/0rocess. Thus, to a human user, it appears that 
more than one job/0rocess is t>eing executed at a given 
time. 

[0003] Some computer systems execute "multi- 
threaded" computer programs in which muHipie 
"threads" of a process can be executing at the same 
time. Multi-threading adds an extra note of complexity to 
the operating system arxj to processor sharing. 
[0004] In at least one implementation of the Solaris 
operating system (available from Sun Microsystems. 
Inc.). a Nghest priority job will run for a period of time 
(called a "time quantum") arxi then its priority is redeter- 
mined. There are cun^ently four different scheduling 
classes that define the priorities of the applications in a 
conventional Solaris system: Real Time (RT): System 
(SYS); Interactive (lA). and Timesharing (TS). If. after its 
execution, a job still has the highest priority in the sys- 
tem, it is allowed to run for another period of time (e.g.. 
between 20 to 200 milliseconds), after which the priority 
is redetenmined agcdn. If it is no longer the highest prior- 
ity job in the system after the redetemrttnation, then a job 
that has a higher priority gete to run. Unfortunately, if a 
job maintains a highest priority, other appHcations do 
not alvrays get a chance to exacuta 
[0005] Many conventional operating systems use 
time-sharing processor-scheduling strategies that 
schedule threads independentiy. In such a system, 
each thread Is assigned a prtority and a time quantum 
and is put on a run queue to wait tor its turn to use the 
processor. When a processor is available, it picks the 
thread with the highest priority from the run queue and 
executes it. The thread is allOMved to use the processor 
for the duration of the time quantum When the thread 
uses up its assigned quantum, the thread's priority is 
recalculated, a new time quantum is assigned and the 
thread is put t>ack onto the run queue. The processor 
then picks the next highest priority thread from the run 
queue and begins to execute it again. 



(0006] During its execution on a processor, a thread 
often requires an event to occur or some data or 
resource to t>e available t>efore the thread can continue 
its computation. An example of an event might be a k^ 
5 stroke from a user or availability of a record from affle. 
Similariy, a thread may have to wait for avail€dbility of 
date, such as access to a lock that is shared with 
another thread. A thread that needs a resource is called 
a "consumer thread." When the resource or date is not 
w avedlak)le or when the event has not occurred, and the 
consumer thread needs to wait the consumer thread is 
called a t)k>cked consumer thread." If the event or date 
is not immediately avaHabie. the processor does not 
sinply allow the thread to wait idly while ooct43ying the 
IS processor. Instead, even though the btocked consumer 
thread is not done with ite time quantum, the processor 
puts the k3locked thread on a sleep queue and picte 
another thread to eximite. Th» new ttiread has its own 
preassigned time quantum. Use of a sleep queue altows 
20 a more efficient use of the processor resources. When 
the awaited event occurs or the awaited date or 
resource becomes avaiteble. the processor wakes tiie 
bloGked consumer thread and pute it on the run queue 
to wait for ite turn to use the processor. 
[0007] Although the practice of allowing a thread to 
"sleep" while btocked altows a more efficient use of the 
processor, it incura extra overhead because the proces- 
sor has to take time to pick the next highest thread to 
execute. In addition, this approach can (rmit the perform- 
ance of certain multi-threaded applications. Assume, for 
example, that a multi-tfveaded application has two 
threads: thread A and thread B, wfiich share a common 
took executing f n a system with on e processor. Thread A 
holds the lock and is waiting on the run queue for tiie 
processor. Thread B is executing on the processor, but 
requires tiie lock to continue. The lock is not available 
because thread A is hokling it Thus, tivead B is 
bloctod. to wait Ibr the fock. When thread B is Uockad, 
the processor pk^ a thread having a Mghest priority 
from the run queue. 

[0008] Unfortunately, the thread that the processor 
picks may not be thread A. The thread on the run queue 
having the hi^est prforify may not even t>e for the same 
process as threads A and B. If the processor picks a 
thread from a different process, the processor wilt have 
to peribmn an ineffkaent and costly context switch (to 
execute threads of a new process). When thread A 
finally does run. another context switch wfll be required 
(to execute threads of the process of ttveacte A arxJ B). 
Even worse, by the time thread A (whl^ has the lock) 
executes, thread B (which needs the fock) may not k>e a 
highest priority process on the run queue arxJ may not 
execute right away. This type of scenario demo n str ate s 
one reason wtiy multi-threaded applications can per- 
form poorly in a shared execution system. 
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SUMMARY OF THE INVENTION 

[0009] A described embocfimant of the present inven- 
tion provides a method and apparati^ for allowing a 
thread to "share" its time quantum with other threads 
when the thread is btocked. A thread may be blocked, 
for example, if it is waiting for a resource such as a data 
file or a lock A thread n«y also be blod^ if it is waiting 
for an event such as a user keystroke. 
[001 0] A 'oMisumer thre^ is defined as a thread that 
needs to consume a resource or to wait for an a^ent In 
a first embodiment of the present invention, when a 
thread is to be blocked. If there another thread waiting 
for execution that is from the same process and that 
"owns" the resource needed by the blocked consumer 
thread, the blocked consumer thread transfBrs Hs right 
to exeotte for its remaining time quantum to the owner 
thread, and the owner thread executes next This trans- 
fer means that no process context switch e required, 
since the blocked consumer thread and the owner 
thread are threads of the same procesa In additkm. this 
transfer means thai the time before the resource 
becomes available to the blocked consumer thread wiD 
be short 

1001 1] In another embodimerrt, the OMmer thread may 
betong to a diflerent process than the first thread, if the 
two processes are both owned by the same user. In this 
enrtxxilment, the first thread shares its renr^nirtg time 
quantum with the second thread, although a corrtext 
switch may be needed. In another embcidiment the 
owner thread nuiy belong to a different prooees than the 
first thread and the two processes may l>e owned l>y dif- 
ferent users. If the system defines the first user as bemg 
able to share resources with the second user, the first 
thread shares its time remaining time quantum with the 
second thread, although a context switch may be 
needed. 

[0012] In another embodiment of the present inven- 
tion, when a thread is bkxd<ed, if the owner thread is 
also blocked, the blocked corwumer thread transfers its 
right to execute for its remaining time quantum to 
anotha- thread that is not the owner thread, but that is 
still in the same process. This transfer means that no 
process context switch is required, since the bk)cked 
consumer thread and the thread to which the remaining 
time quantum is transferred are threads of the same 
process. 

[001 3] In another embodiment in the case where the 
owner ttvead is bk>cked, the thread that is not the owner 
thread may belong to a dlff^ent process than the first 
thread, if the two processes are both owned t>y the 
same user. In this case, the blocked thread shares its 
remaining time quantum with the thread tiiat is not the 
owner thread, although a context switch may be 
needed. In another embodiment, ttie thread that is not 
the owner thread may belong to a different process than 
the first thread arxl the two processes may be owned k>y 
diff^ent users. If the system defines the first user as 



being able to share resources with the second user, the 
first thread shares its remaining time quantum with the 
second thread, although a context switch may be 
needed. 

5 [0O14] Similarly, if a oonsunrter tturead to blocked to 
wait for an event such as a user keystroke, the remidn- 
ing portkm of the consumer thread's time quantum is 
transferred to another thread of the same process that 
is waiting on the run queue for its tum to execute. This 

10 second thread may have a highest priority or may l^e 
chosen according to any other appropriate criteria. 
Again, this transfer avoids having to perform a context 
switch between processes. 

[Q015] In another embodiment, when the blodted 
75 thread is waiting for an event the triocked thread may 
share its remaining time quantum with another thread, if 
the two processes are both owned by the same user In 
this case the bkxked thread shares its remaining time 
quantum with the second thread, although a context 
20 switch may be needed In another emtxxfiment, the sec- 
ond thread may belong to a different process than the 
first thread, and the two processes may be owned by 
different users. If the system defines the fvst user as 
being able to share resources with the second user, the 
25 first thread shares its remaining time quantum with the 
second threed, although a context switch may be 
needed. 

10016] In accordance with the purpose of the inven- 
tk)n, as embodied and broadly described herein, the 

30 invention relates to a method of sharing a time quantum 
between threads in a process, compri^g the steps, 
performed by the data processing system, of: determin- 
ing that a first thread, which is currently t>eing executed 
by a processor and which has en associated time quan- 

35 tum. is blocked; detemnbiing a next thread to be exe- 
cuted by the processor; and transferring unused time in 
the time quantum of the first thread to the next thread to 
be executed. 

[0017] In further accordance with the purpose of the 

40 invention, as entxxfied and tsroadly descrik>ed herein, 
the invention relates to method of sharing a time quan- 
tum t)etween a plurality of threads In a data processing 
system, comprising the steps, performed by the data 
processing system, of: initiaily assigning a number of 

45 tickats to the plurality of threads; assigning an Initial pri- 
ority to a thread of each of the plurality of processes in 
accordance with the number of tickets assigned to the 
threads; and executing the respective threads of the 
plurality of processes in an order incficated t>y the tickets 

so assigned to the plurality of threads, so that the propor- 
tion of executkm time between any two of ttte threcds is 
the same as the proportion t^etween tiie number of tick- 
ets of the two processes associated with the threads, 
the execution step inducfing the sut)steps of: determin- 

55 ing that a first thread, whl^ is cun'entfy k>eing executed 
arvJ which has cm associated time quantum, Is trfocked; 
determining a next thread to execute; and transferring 
unused time in ttie time quantum of the first thread to 
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the next thread to execute 

[0018] A fuHer understanding of the invention wffl 
become apparent and appreciated tjy referring to the 
(bllcwing description and dainis taken in conjunction 
with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[001 9] The aooompanying drawings, which are Incor- 
pOTGrted in and constitute a part of this specification, 
illustrate several embodiments of the invention and, 
together with the description, serve to explain the prind- 
pies of the Invention. 

Fig. 1 shows an example of a plurality of multi- 
threaded appGcations executing on a data process- 
ing system having a single processor, in accord- 
ance with a preferred embodiment of the present 

invention. 

Fig. 2 shows an example of a plurality of multi- 
tfireaded appScatlons executing on a data process- 
ing system having multiple processors, in accord- 
ance with another preferred embodiment of the 
present invention. 

Fig. 3(a) shows an example of a data structure 
used to implemertt a emtxxliment of the present 
invention in a system where rrajHi-threaded applica- 
tions share one processor (such as the system of 
Fig. 1) using a ticket metaphor. 
Fig. 3(b) shows an exarrple of a data structure 
used to implement a preferred emlsodinnent of the 
present invention in a system where multi-threaded 
applications shara more tfian one processor (such 
as the systems of Fig. 2) using a ticket metaphor. 
Rgs. 4(a) and 4(b) are flow charts descrQnng a of 
the present invention in a system where multi- 
threaded applications share at least one processor 
(such as the sy^em of Figs. 1 or 2) using a tid^t 
metaphor. 

Fig. 4(c) is a flowchart describing a method per- 
formed when an executing tfvead is kslocked and 
transfers its remaining time quantum to another 
thread. 

Fig. 4(d) is a flow chart descrft»ng a method per- 
formed when a thread to which time a was trans- 
ferred completes with time still remaining. 
Rg. 5 shows an example of a data structure used to 
implement a preferred embodiment of the present 
invention in a system where multi-threaded appUca- 
tions share more than one processor (such as the 
system of Rg. 2) without implementing the ticket 
metaphor. 

Rg. 6 is a flowchart describing a mettiod performed 
when an executing thread is blocked and transfers 
its remaining execution time to another thread in the 
same process, without implementing the ticket met- 
aphor. 



DETAILED DESCmPTION OF PREFERRED EMBOD- 
IMENTS 

10020] Reference will now by made in detail to pre- 
5 fOTed embocfinrients of the irivention, examples of whk:h 
are illustrated in the accompanyirtg drawing Wherever 
convenient the same reference numt)ers will be used 
tivoughout the drawings to refer to the same of like 
parts. 

10 

I. Overview 

[0021 ] The present Invention can be implemented on 
a wkle variety of data processing systms, including 
IS systems tfiat execute rrulti-threaded applicatiors and 
that include a single processor or multiple processors. 
Figs. 1-2 show respective exanples of each of these 
systems. 

[P022] The present invention can t>e implemented in 

20 any appropriate data processing system that includes 
nudti-threading or similar concepts. Beccuise the inven- 
tion allows a thread that is btockad to share its uraised, 
allotted e3eecution time with other threads, the present 
invention improves the efficiency of execution of threads 

25 in the process arxJ avoids undesirable process context 
switches asxi delays in executing threads (when the 
tiveads shcuing time quantum are in the same process). 
IP023] Figs. 3 and 4 show an embodiment of the 
presmt invention that allows sharing of execution rights 

30 among threads using a Ifcket" metaphor, as descr&ed 
below. Rgs. 5 and 6 show an emtxxtiment of tiie 
present invention that does not use the *1icker meta- 
phor. Thus, the present Invention can be used in a vari- 
ety of operating system environments, and can be used 

55 In contexts that do or do not use a *tk:ket" metaphor for 
sharing processor resources without departing from the 
spirit and scope of the present invention. 
[D024] Fig. 1 is a block diagram of a data processing 
system 100 having a single processor 102 and a mem- 

40 ory 104. Memory 104 includes one or more nmiti- 
threaded applications (also called "processes'^ 1 10. at 
least one of which contains a plurality of tiireads 112. 
Memory 104 also includes an operating system (OS) 
108, which includes process scheduler software 109. 

45 The steps of the described enrixxfiment of the present 
invention are performed when instructions in process 
scheduler software 109 are executed by processor 102. 
The present invention allows the threads 112 of each 
multi-threaded application/t^rocess 1 10 to share proces- 

60 sor 102. as described l>elow. 

(P025] Data processing system 100 (and other data 
processing systems discussed herein) can be, for 
example, a SPARC chip based system, an Ultra senrar, 
or an Enterprise server (all of which are avEUlatile from 

55 Sun Microsystems. Inc.). Data processing system 100 
can also be cmy other appropriate data processing sys- 
tem. 

10026] Operating system 108 can be. fbr exanrple. a 
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varration of the Unix opeiafing system that has k>een 
modif ied to incorporate the present invention. UNIX is a 
r^stered trademark in the United States and other 
countries and is exdusiveiy licensed kjy X/Open Com- 
pany UJ. Operating systm 108 can be, for example, a s 
variation of the Solaris operating system, available from 
Sun Micr o sys tems , Inc. that incorpmrtes the functional- 
ity of the present invention. 

[0027] Fig. 1 also includes an input device 150, such 
as a keytx>ard, mouse, touchpad, touch saeen, etc Rg. io 
1 further includes a cfisplay device, such as a display 
screen, etc. Fig. 1 further includes a computer readatde 
medium 162 and an input device 161 for computer read- 
able mecfium. Computer readable medium 162 
includes, for example, a floppy disk drive. CD ROM is 
reader, or OVD reader, that reads computer instructions 
stored on a computer readable medium, such as a 
floppy disK a CD ROM. or a DN^D drive. Rg. 1 also 
includes network oonnectk)ns 105, which can be 
present in at least some implementations of the system 20 
100. 

[0028] In the following discussion, it will be understood 
that the steps of methods and flow charts discussed 
preferably are performed by processor 102 (or another 
appropriate processor) executing instructions stored in 25 
memory 104 (or other appropriate memories). It wiQ 
also be understood that ttte invention is not limited to 
any particular implementation or programming tech- 
nique and that the Invention may bB implemented using 
any appropriate technkiues 16r implennenling the func- so 
tionality descrit>ed hereia The invention is not limited to 
any particular progranming language or operating sys- 
tem. 

[0029] The instruction in menrKxry may t3e read into 
memory from a computer-readable medium. Execution 35 
of sequences of instructions contained in memory 104 
causes processor 102 to perform the process steps 
desafeed herein. In alternative embodiments, hard- 
wired circuitry may be used in place of or in combination 
with software instructions to Irnplement the invention. 40 
Thus, embocfiment of the invention are not limited to any 
specific oomtNnation of hardware circuitry and softwara 
[0030] The term "computer-readable mediim** as 
used herein refers to any medium that partidpates In 
providing instructions to a processor for execution. Such 45 
a medium may take many forms, inducing but not lim- 
ited to. non^volatile media, volatile media, and transmis- 
sion media. Non-volatile media includes, for example, 
optical or magnetic disks, such as a storage device. Vol- 
atile media includes dynamic memory. Transmission 60 
media indude coaxial cables, copper wire and fiber 
optics, induding the wires ttiat comprise a txis within a 
computer. Transmission media can also take the form of 
acoustic or light waves, such as those generated during 
radio^wave and infra-red data communications. ss 
[0031] Common forms of corrputer-readatile media 
indude. for example a floppy disk, a f lexit)le disk, a hard 
disk, magnetic tape, or any other magnetic medium, a 



CD-ROM. any other optical mecfium. punchcaitte. pap- 
ertapes. any other physical medium with patterns of 
holes, a RAM. a PROM, an EPROM. a FLASH-EPROM. 
any oflier memory cftip or cartrklge. a carrier wave, or 
any other medium from which a computer can read. 
[0032] VSeuIous forms of computer readable niedia may 
be involved In carrying one or more sequences of one or 
wore instructions to a processor for execution. For 
example, the ir^tructions may initially be carried on a 
magnetic disk of a remote computer. The remote oom- 
puter can load the instructions into its dynamic memory 
and send the instructions over a teleftfione line using a 
modem. A modem local to the computer system can 
receive the data on the telephone Hne and use an infra- 
red transmitter to convert the data to an infra-red signal. 
An infra-red detector coupled to a bus can receive the 
data carried in the infra-red signal and plaoe the data on 
the bus. The bus carries data to main memory, from 
which a processor retrieves and executes the instruc- 
tions. The iretructions received lay main memory may 
optionally be stored on a storage device either before or 
after execution kiy a processor. 
[0033] It will be understood that the present invention 
can also be performed in a distributed data processing 
system, where the proces8or(8) and memory are 
kx»ted in different macNnea It will also t>e understood 
that the present invention can also be implemented in a 
distrftHited system, where the processes, threads, 
and/or processors are not all in the same computer. 
(0034] A person of ordinary skill in the art will under- 
stand that memory 104 also contains additional infor- 
mation, such as appTication programs, operating 
systems, data. etc.. whch are not shown in the f igure for 
the sake of darity. It also wifl be understood that data 
processing system 100 (or any other data processing 
system described herein) can also indude numerous 
elements rx)t shown, such as disk cfa^ives. k^/tx^ards, 
display devices, network connections, additional mem- 
ory, additional CPUs. LAMs. input/bulput Ones, etc. 
I0O35] Fig. 2 is a tslock diagram of a data processing 
system 200 having multiple processors 102' and a 
memory 104. Memory 104 indudes one or more multi- 
threaded applications 110 (also called a "process"), at 
least one of which contains a plurality of tiireads 112. 
Memory 104 also Indudes an operating system (OS) 
108. wtiich indudes process scheduler software 109. 
The steps of the desanbed entxxJiment of the present 
invention are performed when instructions in process 
scheduler software 1 09 are executed by one or more of 
processors 102*. The present Invention allows the 
threads 112 of each multi-threaded application/process 
110 to proportionally stiare processors 102', as 
descrflded betow. 

II. MultHhreaded Aiqpllcalions 

[0036] Rg. 3(a) shows an example of a data structure 
used to implement a prefenred embodiment of the 
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present Invention in a single processor system capable 
of executing multi-threaded appficatior^ (such as the 
system of Rg. 1). Ftg. 3(b) shows an example of a data 
structure used to implement a preferred embodiment of 
the present invention in a mutti-prooessor system capa- 
ble of executing nulti-threaded appOcations (such as 
the system of Fig. 2). Figs. 4(a) and 4(b) are flow charts 
shewing steps using the data structures of Rgs. 3(a) or 

m 

[0037] In the data structures of Rgs. 3(a) and 3(b), 
mult^e threads in each application/jprocess "share" the 
tickets of their process l^etween them via a ticket data 
structure 305. It should be understood that the systems 
of Rg. 3(a) and 3(b) can also include single-threaded 
applications (not shown), in addition to the mufti- 
threaded applications. This Picketing" system is 
described in more detail in U.S. Application Serial Na 
08/962.140 of VLie. entitled "Method and Apparatus fbr 
Processor Sharing." filed October 31 , 1997. 
[0038] While each thread has its own priority 326. the 
tickets are held at the process level in fields 340 and 
342 of ticket structure 305. Ticket data structure 305 
also includes a #slot8 fieM 346 and a ticket queue 
pointer 347. The #8lots field 346 indicate a number of 
processor slots assigned to each process. In the case of 
a single processor system, the number of slots always 
"1". A multiple processor system can have any number 
of slots less than or equal to the number of processors 
102*. Ticket queue pointer 347 points to a ticket queue 
350, whose function is to hold threads of a process tfiat 
are waiting for a processor slot to become available. 
Threads to be executed are taken off ticket queue 350 
and placed on run queue 103 (or 103*) for execution by 
processor(s) 102 (or 102*). 

[0039] Rg. 4(a) is a f k>w chart 400 showing steps per- 
fbrmed in connection wfth the multi-threaded applica- 
tions of Rgs. 3(a) and 3(b) sharing single processor 1 02 
or nuKqple processors 102*. In step 402 of Rg. 4(a). a 
number of tickets and a number of slots are assigned to 
each process. The priority of a thread is assigned t>ased 
on the nunt>er of current tickets in the ticket structure 
305 of its process when the priority is assigned. Thus, 
threads of a same process can have different priorities. 
[0040] When a tfiread wants to use a processor 102. 
102' (see step 404). it first checks to determine whether 
there is an avEUlable processor slot (step 406). If there is 
an available slot (i.e.. no other thread is waiting in ticket 
queue 350), a priority is determnned for the thread in 
step 408. This priority is placed in field 326 of the 
thread's ps jsrocjt data structure 304 and the thread is 
placed In run queue 103 for execution in step 410. Oth- 
erwise (if there are no available processor slots), the 
thread is placed in ticket queue 350 for this process 
(step 412). When a slot becomes available in step 414, 
a thread is taken off ticket queue 350 and its priority 326 
is calculated in step 415 t>ased on the current numt>6r of 
tickets hekf by its process. The thread is then placed In 
run queue 103 for execution in step 416. 



IP041 ] Rg. 4(b) is a flow chart 430 showing steps fbr 
executing a thread after ttie tfiread Is put on the system 
run queue 103 for execution by processor 102. TT^e 
thread is executed fbr the predetermined time quantum 

5 specified in the time quantum field 320 In step 434. As 
the ttiread exeoites. the "timelefl" field 322 is deae- 
mented fbr each time unit of execution. Thus, the time 
quantum field is a constant value and the timeleft fiekj \s 
regulariy deaemented as the thread executes. The 

10 timeleft Held 322 hoMs tiie amount of execution time 
remaining fbr the thread during its current chance to use 
the processor. After the thread completes execution, the 
#current tickets 342 fbr the process of tiie executing 
tiiread is reduced by "1" in step 43a If the number of 

IS tickets hekJ is '0' in step 438. the number of tickets is 
reset to the initial value for the process in ^ep 440 arxJ 
control passes to step 442. Ottienwise control passes 
directly to step 442 

PX>42] In step 442. if otiier threads are on the ticket 
20 queue 350 fbr this process, the current thre«] gives up 
its stot in step 444 and is put back on ticket queue 350. 
Its slot Is given to the ttiread at the head of ticket queue 
350 and a new priority Is cak:ulated for this new thread 
t>ased on the number of current tickets 342 fbr the proc- 
25 ess in step 446. This new thread (with its newly 
assigned priority) is placed on run queue 103 for execu- 
tion in step 448. 

P043] If. on tiie other handt in step 442 there are no 
threads waiting in the ticket queue 350 when the current 

30 thread finishes execution, the priority of the current 
thread is recalculated based on the number of cunent 
tickets for the process in step 490 and the current thread 
is placed back on run queue 103 in step 492 for execu- 
tion, rskite that steps 446 and 490 recatoulate a priority 

35 Of a thread based on the number of tickets currently held 
by the process to which the ttiread belongs 
[D044] Because tiie system of Rg. 3(b) includes nrul- 
tiple processors 102'. each process is assigned a 
number 346 of "slots" equal, for example, to the number 

40 of processors in ttie system. Ottier implementations of 
tiie present invention may use other numbers of slots. 
R)r example, the nunt>er of slots could be smaller than 
tiie number of processors in the system In order to 
reduce the concurrency of execution of processes. In 

45 the descra^ed entxxfiment. if tfiere are two processors 
in the system, the number of slots would be "2". Thus, 
for example, if there are only two processors 1 02* in the 
system and a process has ten threads, only two threads 
of the process at a time can be input to the system run 

so queue. The rest of the threads will wait on ticket queue 
350. 

[p045] The previous paragraphs discuss a "ticket" 
metaphor used to apportion execution time among nrul- 
tiple threatte. It win be understood that ottier mrthods 
65 can be used to apportion execution times among 
ttireads and that ttie above-desc^bed '^cket" metaphor 
is not necessarily a part of systems implementing the 
present invention. The fbitawing paragraphs describe 
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how threads can share their assigned execution time 
Quantum. 

(0046] Rg.4(c)isaflGMrchart460descrik»ngamethod 
p&formed when an executing cor^mer thread is 
biocked and transfers its remaining time quantum in 
timeleft field 322 to another thread in the same process. 
The "cunrentty executing thread' of step 462 Is the 
thread that is blocked. Steps 462 through 472 are per- 
formed when the consumer ttiread is waiting for a 
resource. Steps 480 through 484 are peifbrmed if the 
consumer thread is waiting for an event 
I0M7] Step 464 determines which of the existing 
threads owns the needed resource using the field ^7. 
This thread is called the "owner." In step 466. if the 
owner is on the run queue 103 for this process (i.e., if 
the owner is not Islocked itself) then, in step 468. the 
timeleft 322 of the blocked consumer thread is trans* 
ferred from that bead's ps jmc Jt data structu re 304 to 
timeleft f iekJ 322 of the ps jsrocjt data structure of the 
owner thread This transfer occurs even if the owner 
thread does not have the higfiest priority of the threads 
on the run queue. The owner thread then started, so 
that it can immecfiately use the remaining time quantum 
in timeleft fiekJ 322 of the blocked consumer thread. 
Because the owner thread is part of the same process 
as the consumer thread, no pfocess context switch is 
required. 

[0048] If. on the other hcuid, in step 470, the owner 
itself is blocked, the remaining time quantum of the 
k)lockBd consumer thread is tra ns ferr e d to the thread at 
the head of the same process of the run queue. The 
thread is then started, so tfiat it can immediately use the 
remaining time quantum of the bkxtod consumer 
thread. Because the newly started thread is part of the 
same process as the consumer thread, no process con- 
text switch is required. This transfer is accomplished, for 
example, by copying the timeleft fieki 322 from the 
t)locked consumer thread second thread Alternately, 
the timeleft fieki 322 of the first thread can be added to 
the timeleft fiekJ 322 of the second thread. 
(0049] Following both steps 468 and 470. the bk)cked 
consumer thread is placed on the sleep queue 354. The 
thread will t>e restarted when its resource becomes 
available. An example of this occurrence is shown in 
Fig. 4(d). 

[0050] St^ 480 determines whether the currently 
executing consumer thread needs to wait for an event 
(as opposed to a tAockod resource). If so. in step 482. 
the remaining time quantum in timeleft field 322 of the 
t)lockad consumer thread is transferred to the p$_procjt 
data structure 304 of a thread at the head of the run 
queue 103. This transfer is accomplished, for example. 
t)y copying the timeleft fieU 322 from the bkKked con- 
sumer thread to the second thread Alternately, the 
timeleft fiM 322 of first thread can be added to the time- 
left field 322 of the second thread. The thread is then 
started, so that it can immediately use the remaining 
time quantum of the blocked consumer thread. Because 



the newly started thread is part of the same process as 
the consumer thread, no process context switch Is 
required. Foftowing step 482, the bfocked consumer 
thread is placed on the sleep queue in step 484. The 

5 thread will be restarted when its event occurs. An exam- 
pie of this occurrence is shown in Rg. 4(d). 
10051] Rg. 4(d) is a ftow chart 490 describing a 
method performed when a thread to which a remaining 
time quantum was transfored conpletes witii time still 

10 remaining. If. In step 492, a ttiread completes its execu- 
tion with unused execution time remaining; if. In step 
494. the thread prcvtously t)orrowed time from a thread 
ttiat is currentiy blocked; and if« in step 496. the blocked 
consumer thread is waiting for data or an event tfiat is 

IS avail&Me (i.e., data that is not btockad or an event that 
has occurred) then. In step 498, the consumer thread is 
restarted and ttie remaining time quantum in timeleft 
field 322 is transferred to the newly restarted thr^. 
IP0521 Rg. 5 shows an example of a data structure 

20 used to Implement an emkxxJIment of the present Inven- 
latm in a system where multi-threffiled applk:ations 
share more tiian one processor (such as the systems of 
Rg. 2) but that does not use ttie ticket metaphor. Note 
that in contrast to the data structure of Rg. 3. the data 

25 structure of Rg. 5 does not indude a ticket structure 
alkjwing ttireads of a single process to share their rigfit 
to executa'on. In this implementation of the present 
invention, the data structure of Rg. 5 includes an "active 
queue" 352 for each process. TTie procjk structure 301 

30 of each process points to tfie active queue 352 for tiiat 
process. Active queue 352 is a list of all threads of the 
process that are currentiy on the run queue. Thus, the 
thread of the process has tiie highest prfority in the run 
queue will be at the head of the active queue for tiiat 

35 process. 

[0053] Rg. 6 is a flowchart 660 descrbing a mettiod 
perfonned when an executing consumer thread is 
tHocked and trEUisfers its remaining exeoition time to 
anotiier thread in the same process, in a system that 

40 does not use ttie ticket metaphor. Rg. 6 is similar to Rg. 
4(c). exc^ that in steps 670 and 682, the time quan- 
tum in fidd 322 remaining for the tsfocked consumer 
thread is transferred to a ttiread at the head of tiie active 
queue 352 fbr the process to which the blocked con- 

45 sumer ttiread belongs. Ttiis transfer is accomplished, 
for exanple. t>y copying the timeleft field 322 from the 
t)locked consumer thread to the second thread. Alter- 
nately, ttie timeleft fieki 322 of the fffst thread can be 
added to the timeleft field 322 of the second thread. 

5D [0054] Thus, In the descrO^ed enrfoodiment of the 
present invention, when a consumer thread is blocked, 
its remaining execution time is assigned to another 
thread In the same process. This thread can be, for 
exanple. a thread that confab a resource that is bfock- 

55 ing the consumer thread. The thread in ttie same proc- 
ess can also be a thread in ttie same process having a 
highest exewtion pnority. Several implementations of 
ttie present invention have t>een discussed herein. A 
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first implementation d6scnt>ed in a system where 
threads of a process share "tickets" among thenselves. 
A second imptem&rtation is described in a system 
where each process Keeps track of its threads that are 
waiting to execute using an active queue or an active 
list In either case, the consumer thread ttet is t3te)cked 
transfers its unused, alkstted execution time to another 
thread in the same process. 

[005S1 While the invention has l3een described ni con- 
junction with a specific embodiment, it is evident that 
many alternatives, nnodificatkins and variations will t>e 
apparent to those skilled in the art in light of the forego- 
ing description. For example, threads in the system can 
either have the same time quantum initiatiy assigned in 
fieki 320 or can have differing time quanta initially 
assigned in field 320. As another example, when a first 
thread is blocked because a resource owned by another 
thread is not available, Hs remaining tvne quantum can 
be transfenred to the owner tfuread. when the owner 
thread is not in the same process, but is owned t>y the 
same user. In this case, the time quantum in timeleft 
field 322 of the first thread (in a first process) wouU be 
transferred to the second thread (in a second process), 
as desabed abova Sinrilariy. in another embodiment, a 
blocked tfvead can share its remaining time quarrtum 
with an owner thread in a different process that belor>gs 
to a different user in a predetermined group of users. In 
this case, the remaining time quantum 322 of the first 
thread (belonging to the first user) would be transferred 
to the second thread (bekxiging to another user in the 
group of users), as descri>ed above. 
[0056] As another example, when a first thread is 
bloctod because a resource owned by another thread 
ntii available, and when the owner is also not availak)le, 
the remaining time quantum of the first blocked thread 
can be transferred to a second thread other than the 
owner thread, when the second thread is not in the 
same process, but is owned by the same user. In this 
case, the remeuning time quantum 322 of the first tfvead 
(in a first process) would be transferred to the second 
thread (in a second process), as descra)ed above. Sim- 
ilarly, in another emtxxiiment, a t3k>cked thread can 
share its remairting time quantum with a thread other 
than an owner thread owner thread in a different proc- 
ess thiat belongs to a different user in a predetermined 
group of users. In tfits case, the remaining tinne quan- 
tum 322 of the first thread (bekmgtng to the first user) 
would i)e transferred to the second thread (betonging to 
anotfier user in the group of users), as desa1t>ed above. 
[0057] As another example, when a first thread is 
blocked k>ecause it is waiting for an event its remaining 
time quantum can be transferred to a second thread, 
when the second thread is not in the same process, but 
is owned by the same user. In this case, the remaining 
time quantum 322 of the first thread (in a first process) 
would be transferred to the second thread (in a second 
process), as described above. Similarty, in another 
embodiment, a kslockad tfvead can share its remaining 



time quantum with a second threitti in a diff^ent proc- 
ess that t>elongs to a diff^ent user in a predetermined 
group of i^rs. In this case, tfie time remaining quan- 
tum 322 of the first thread (l>ek>nging to the first user) 

5 would be transferred to the second tlvead (belonging to 
another user in the group of users), described above. 
[00581 Accordingly, it is intended to embrace afl such 
alternatives, modificalior« and variatims as faO within 
the spirit and scope of the appended claims and equiv- 

10 alents. 

Claims 

1. A metfiod of sharing a lime quantum between 
IS threads, comprising the steps, performed by the 

data processing system, off: 

determining that a first thread, which is cur- 
rently iMing executed by a processor and 
20 which has an assodated time quantum, is 

blocked: 

detenrvning a next thread to be executed by 
the processor; and 

transferring unused time in the time quantum of 
25 the first thread to the next thread to t>e exe- 

cuted. 

2. The method of daim 1, wherein the determining 
step includes the step of determining a next thread 

30 to be executed ttmt is firom tfie scune process as the 
first thread. 

3. The method of daim 1, wherdn the determining 
step indudes the step off determining a next tiirrad 

35 to be executed that is from a different process than 
the first thread. 

4. The method of daim 1, wherein the determining 
st^ indudes the step of determining a next thread 

40 to be executed that is from a different process of a 
different user than the fffst thread. 

5. The method of daim 1, wherein the transfening 
step indudes the st^ of adding the unused time in 

4s the time quantum of the first thread to a time quan- 
tum of the next tfvead to execute. 

6. The method of daim 1 , wherein the transferring 
step irx?ludes the step of transferring the unused 

so time in the time quantum of the first thread to a time 
quantum of the next thread to execute, in place of 
an original time quantum for the next thread to exe- 
cute. 

55 7. The method of daim 1 , 

wherein the first thread in the determining 
step is t)eing executed tyy a first processor of a plu- 
rality of processors. 
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wherein the determintng step detemtines a 
next thread to be executed by the fiist processor, 
and 

wherein the transferring step transfers 
unused time in the time quantum of the fir^ thread 5 
to the next thread to be executed by the first proces* 
sor. 

8. AmettKxJof sharing a time quantum between a plu- 
rafityof threads in a data processing system, com- 10 
prising the stepa peribrmed by the data processing 
system, of: 

initially as»gnsng a number of tickets to the plu- 
rality of threads; is 
assigning an initial priority to a thread of each 
of the plurality of processes in accordance with 
the number of tickets assigned to the threads: 
and 

executing the respective threads of the plurality 20 
of processes in an order indicated by the tidots 
assigned to the pluratity of threads, so that the 
proportion of execution time t)etween any two 
of the threads is the same as the proportion 
between the number of tickets of the two proc- 25 
esses associated with the threads, the execu- 
tion step Including the substeps of: 

determining that a first thread, which is 
currently being executed arxJ which has an so 
associated time quantum, is k)lockBd; 
determining a next thread to execute; and 
transfening unused time in the time quan* 
tum of the first thread to the next thread to 
execute. ss 



furtfier including the step of placing a thread 
associated with a one of the plurality of proc- 
esses onto a processor run queue when there 
is an available processor slot 

11. The method of daim 10. further including the step 
Of catouSating a priority of the thread in accordance 
with the number of tickets currently held by the 
thread's process before the thread placed on the 
run queue. 

12. The methodofdajm 11, wherein ttieexBcufing step 
includes the steps off: 

decrementing a number of tickets of a one of 
the plurality of processes whose thread has 
just finished executing for a predetermined time 
period; and 

if the numt)er of tickets for the one process is 
equal to zero after the decrementing step, set- 
ting the number of tickets for the one process to 
the initially determined number off tickets for the 
one process. 

13. The method of daim 11, wherein the executing step 
includes the steps of recalculating the number of 
tickets held by the process; after the thread of the 
process has executed for the predetermined period 
of time. 

14. Tbemethod of daim 11, wherein the executing step 
Indudes the steps of checking whether there is 
anotiier thread with a Ngher priority; after the 
thread tias finished executing for the predetemvned 
period of time. 



9. The method of daim 8. wherein the data processing 
system includes a plurality of processors, aixt the 
data processing system has a plurality of processor 
slots; 40 

wherebi the executing step indudes ttie step 
of delenmining whether there is an available proc- 
essor slot; and 

further induding the step of pladng a thread 45 
assodated witti a one of the plurality of proc- 
esses on a tidcet queue of the process, when 
there is no available processor slot, so that the 
ttiread waits on the ticket queue fbr an avallatrie 
processorsfot so 

1 0. The method of daim 8, wherein the data processing 
system indudes a plurality of processors, and the 
data processing system has a plurality of processor 
slots; 55 

wherein the executing step indudes the step 
of determ^ing whether there is an availak)le proc- 
essor slot; and 



15b The mettiod of daim 8. wherein at least one of the 
plurality of processes is a multi-threaded applica- 

tim. 

16. An apparatus to alkiw sharing a time quantum 
between ttireads In a process, comprising: 

a portion configured to determine that a first 
thread, which is cunrentfy being executed by a 
processor and which has an assodated time 
quantum, is t)locked; 

a portfon configured to determine a next thread 
to t>e executed by the processor; and 
a portion configured to transter unused time in 
the Hme quantum of the first thread to tfie next 
tiiread to be executed. 

1 7. The apparatus of daim 1 6, wherein the determining 
portion includes a portion configured to deterihine a 
next thread to be executed that is from ttie same 
process as the f iist thread. 
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18. The apparatus of daim 16. wherein the detemraning 
portion inctudes a portion configured to determine a 
next thread to be executed that is from a different 
process than the first thread. 

5 

19. The apparatus of daim 16. wherein the transferring 
portion indudes a portion configured to add the 
unused time in the time quantisTi of tfie first thread 
to a time quantum of the next thread to executa 

10 

20. The apparatus of daim 16. wherein the transferring 
portion includes a portion configured to transfer the 
unused time in the time quantum of the first thread 
to a time quantum of the next thread to execute, in 
place of an original time quantum fbr the next is 
thread to execute. 

21. A computer program product, comprising: 

a oonputer usak^e medium having computer so 
readat)le code entxxlied theron for sharing a 
time quantum between threads in a process, 
the computer program product mdudirig: 
computer readable program code devices con- 
figured to cause a cornputer to effect determin- 2S 
ing that a first thread, which is currently being 
executed by a processor and which has an 
assocttted time quantum, is blod^: 
computer readaJble program code devices con- 
figured to cause a computer to effect determin- so 
ing a next thread to be executed by the 
processor; and 

computer readable program code devices con- 
figured to cause a conrputer to effect transfer- 
ring unused time in the time quantum of the first 3s 
thread to the next thread to be executed. 

22. A computer data signal embodied In a carrier wave 
and representing sequences of instructions which, 
when executed by a processor, cause the proces- 40 
sor to share a time quantum t>etween threads in a 
process by performing the steps of: 

determining that a first thread, which is cur- 
rently being executed by a processor arxi 4s 
which has an associated time quantum, is 
bkxtod; 

determining a next thread to be executed by 
the processor: and 

transferring unused time in the time quantum of so 
the first thread to the next thread to be exe- 
cuted. 
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